fix(offset): accept MEZ, MESZ, MEST and KST abbreviations - #321
Conversation
The table is meant to cover the same abbreviations GNU date supports, but these four were missing, so `date -d "2024-01-15 12:00 MEZ"` failed here while GNU accepts it. Offsets were measured against GNU coreutils: MEZ is +1, MESZ and MEST are +2, and KST is +9. Downstream this is what pushes uutils/coreutils to keep its own abbreviation table in date.rs and parse the string in fragments, which is the root of uutils/coreutils#13865.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #321 +/- ##
=======================================
Coverage 99.33% 99.33%
=======================================
Files 21 21
Lines 4051 4061 +10
Branches 129 129
=======================================
+ Hits 4024 4034 +10
Misses 26 26
Partials 1 1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Merging this PR will degrade performance by 3.66%
|
| Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|
| ❌ | parse_weekday |
62.1 µs | 64.5 µs | -3.66% |
Tip
Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.
Comparing ARMeeru:fix/missing-gnu-timezone-abbreviations (5266ff2) with main (46fb737)
2 participants
timezone_name_to_offsetdocuments its own scope as matching GNU:Four abbreviations GNU accepts are missing from the table, so they fail here:
MEZis +1,MESZandMESTare +2, andKSTis +9.How these four were picked
Rather than adding only the ones I happened to run into, I compared the crate against GNU across 100 candidate abbreviations: everything already in this table, plus the ones
uutils/coreutilscarries indate.rs, plus a spread of common world abbreviations. GNU accepted 72 of them and the crate agreed on 63. The other nine fall into two groups.Four the crate rejects outright. Those are in this PR.
Five where both accept but the offsets disagree:
ADT,AST,BST,GSTandSST. Every one of those is a genuinely ambiguous name (Atlantic or Arabia, British or Bangladesh, Gulf or Guam), and changing a value that already exists is a different sort of decision from filling a hole. I left them alone. Happy to open an issue with the measurements if you want them tracked.Where the offsets came from
Each one was measured by running GNU date and comparing instants, for example:
GNU coreutils 9.1. These came from running GNU date and reading its output, not from reading its source.
Tests
The four are added to the existing
timezone_name_without_offsetlist. That test fails before the change and passes after. The rest of the suite is unaffected.Context
This gap is part of why
uutils/coreutilskeeps a separate abbreviation table indate.rs, which came up in uutils/coreutils#13865. This change does not remove that table on its own, and the two are independent.